Zerochain TODOリスト
メインのマイルストーンとは関係ないけどセキュリティ的にやらねばなことのリスト
Must系
まだやれてないけど追加実装系でやらねばなこと
get generator points to be added personalizations
独立した異なる用途のGenerator pointsは別々に。
zeroed memory for sensitive data
Fix to only use non-hardened key because of clamings in ed25519
use json-core-client crate in polkadot.rs
rpc client実装クソなので、type safety and futurify
osuke.iconDone：Client side checking against verifying a proof
osuke.iconDone：alphaをランダムに
std & no_std partのduplicated実装解消
複合化用の楕円曲線pointの保持
osuke.iconDone：module内での型変換をやめて、substrate primitives型の演に演算に。
osuke.iconDone：preparedVerifyingKeyのmodule内byte castを避ける
decryption key fileの受け渡しinterface（送金額監査用）
送金乱数の受け渡しinterface（送金者通知・監査用）
osuke.iconDone：transaction内の暗号乱数部分の共通化
osuke.iconDone：zk_system moduleの追加( zk_verify, nonce_pool, epoch管理）
Update系
依存ライブラリのbreaking change含むバージョンアップ
Bump librustzcash version up to latest
Seperate ff crate from pairing crate
Bump rand crate to v0.7
Change blake2_rfc to blake2_simd
Check系
暗号学的な脆弱性を含む可能性がある実装をチェック
Biased randomness
Cofactors (in keys and hdkd)
First private key
Is it done correcly by E::Fs?
decryption key
Some read functions from bytes in keys.
loss of security bits by unnecessary multiplication
circuit implementations
especially, range proofs
overflow checkings
potential side-channel timing attacks
review part of generating proofs and verification of it
Encoding / Decoding
Test系
fuzzy testing
range check part
Testing for edge-cases
Epoch問題
最適なエポック数の算出
g_epochがずれる
クライアントでのepoch取得時 -> runtimeでのepoch取得のタイムラグでblock高が進みずれる
同じg_epoch内送信
rolloverが起きずenc_balanceのみがzk public inputに与えられてしまう。クライアントではenc_baance + pending_transferを想定してzk proofしている。
InvalidZkProof でtx送信をretry?
パフォーマンス
ProvingkeyとPrepatedVerifyingKeyのバイトキャスト処理を並列処理化
追加
remote nodes/light clientsの実装